Module / Project file size

Hi everyone,

How can I get information on DOORS 9.4 about the size (on disk) of projects and modules in the database?
I'm planning to archive a large project and restore it in another database. To do so, I need to know the size of this project, to make an estimation of the time I'll need keep the original database offline.
 

Thanks in advance,

Tiago

 


Portolon - Wed Feb 11 08:36:28 EST 2015

Re: Module / Project file size
llandale - Wed Feb 11 10:18:48 EST 2015

Don't know.  But I suppose if you were running DXL on a client on DOORS server, you could:

  • For every module in the Project, including deleted modules
  • turn the module into a folder name within the database
  • use the file-access functions and "Stat" handles to find every file in the module's folder, and accumulate the total size.

the base folder of a module looks like this:

  • string NameWindowsFolder_Mod = "m" (uniqueID(module(fullName(itm)))) ".mod"

You can deduce where in the server the database is housed, starting with this:

  • print (confCopyFile("ThisFileDoesNotExist.xxx8ej3mn3hdhd.ddd", "xxx", confSystem))"\n"

Given the DB root and the base name of the module's folder, you can find that windows folder.

I don't think anybody has ever done that, sorry.

Run the archive directly on the DOORS server.  This will drastically reduce how long it takes.

-Louie

I may be tempted to time how long it takes to open every single module in the Project, and use some calibration to estimate how long it would take to archive.  Calibrate by archiving some very small project first.

I would also be inclinded to try this: disable user logins, copy the project, enable user logins, then archive the copy.  I'm guessing the copy takes less time than does an archive.

Re: Module / Project file size
Portolon - Thu Feb 12 06:30:57 EST 2015

llandale - Wed Feb 11 10:18:48 EST 2015

Don't know.  But I suppose if you were running DXL on a client on DOORS server, you could:

  • For every module in the Project, including deleted modules
  • turn the module into a folder name within the database
  • use the file-access functions and "Stat" handles to find every file in the module's folder, and accumulate the total size.

the base folder of a module looks like this:

  • string NameWindowsFolder_Mod = "m" (uniqueID(module(fullName(itm)))) ".mod"

You can deduce where in the server the database is housed, starting with this:

  • print (confCopyFile("ThisFileDoesNotExist.xxx8ej3mn3hdhd.ddd", "xxx", confSystem))"\n"

Given the DB root and the base name of the module's folder, you can find that windows folder.

I don't think anybody has ever done that, sorry.

Run the archive directly on the DOORS server.  This will drastically reduce how long it takes.

-Louie

I may be tempted to time how long it takes to open every single module in the Project, and use some calibration to estimate how long it would take to archive.  Calibrate by archiving some very small project first.

I would also be inclinded to try this: disable user logins, copy the project, enable user logins, then archive the copy.  I'm guessing the copy takes less time than does an archive.

Hi llandale,

Thanks for answering.

I used a log file (given by backup operation) to locate the folders of the latest backup version, and copied them to a new folder outside the DB. The archive and restore operation is intended to serve for a test - so there isn't a need for the very last version of the project.

How can I make the archive operation? Can this create some conflict in the database (since the folders inside the new folder have the same names of  those that are in the backup location)?